config/oauth.php-15-25 (1)

15-25: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

OIDC_ prefix is inconsistent with all other OAuth config env vars

The config comment says "auto-created OAuth/OIDC users" (covering Google, GitHub, GitLab, and OIDC alike), but the env variable is named OIDC_DEFAULT_ORGANIZATION_ID. Every other option in this file uses the OAUTH_ prefix. An operator configuring Google or GitHub OAuth will not expect to look for an OIDC_-prefixed variable to control organization assignment.

🔧 Suggested rename

-    'default_organization_id' => env('OIDC_DEFAULT_ORGANIZATION_ID'),
+    'default_organization_id' => env('OAUTH_DEFAULT_ORGANIZATION_ID'),

Update .env.example and the documentation page accordingly.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@config/oauth.php` around lines 15 - 25, The env var for the config key
default_organization_id is incorrectly using the OIDC_ prefix
(OIDC_DEFAULT_ORGANIZATION_ID) which is inconsistent with other options; change
the env lookup to use OAUTH_DEFAULT_ORGANIZATION_ID in the config
(default_organization_id => env('OAUTH_DEFAULT_ORGANIZATION_ID')), and update
any related artifacts (e.g., .env.example and documentation) to reflect the new
OAUTH_ name so Google/GitHub/GitLab operators can find the setting.

tests/Feature/DatabaseServer/CreateTest.php-17-18 (1)

17-18: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Organization::first()->id will fatal-error if no Organization exists.

Every Volume::create() call uses \App\Models\Organization::first()->id (without the null-safe operator). If an Organization isn't in the database at the moment this line executes — due to test isolation, a changed seeding order, or a future test refactor — PHP will throw a fatal error trying to access ->id on null. The DatabaseServerFactory already uses the defensive form Organization::first()?->id ??.

🛡️ Proposed fix (representative example — apply to all occurrences)

-'organization_id' => \App\Models\Organization::first()->id,
+'organization_id' => \App\Models\Organization::first()?->id ?? \App\Models\Organization::factory()->main()->create()->id,

Alternatively, extract a shared mainOrganization() test helper (similar to the existing dailySchedule() / weeklySchedule() helpers visible in the file) to avoid repeating this across every test.

Also applies to: 110-111, 149-150, 268-269, 296-296, 313-313, 330-330, 356-357, 433-434, 474-475, 480-481

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/DatabaseServer/CreateTest.php` around lines 17 - 18, Replace
unsafe Organization::first()->id usages in Volume::create() calls with a
null-safe fallback to ensure tests don't fatal when no Organization exists;
specifically update each occurrence of Organization::first()->id to use
Organization::first()?->id ?? Organization::factory()->create()->id (or call a
shared helper like mainOrganization() that returns an existing id), and mirror
the defensive pattern already used in DatabaseServerFactory so all referenced
locations (e.g., the Volume::create(...) calls) use the null-safe operator plus
a create fallback.

app/Services/CurrentOrganization.php-130-135 (1)

130-135: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Organization::main() may return null; switchTo(null) will TypeError.

If main() returns null (e.g., the backfill migration failed to seed it, or a super_admin was created against a freshly-migrated schema where seeding didn't run), switchTo(Organization::main()) violates switchTo(Organization $org). Same null-safety story applies if the main org row was manually deleted in production. A defensive if ($main = Organization::main()) plus log-or-throw on the else branch keeps the failure mode comprehensible.

         if ($user->isSuperAdmin()) {
-            $this->switchTo(Organization::main());
-
-            return;
+            $main = Organization::main();
+            if ($main !== null) {
+                $this->switchTo($main);
+            }
+
+            return;
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Services/CurrentOrganization.php` around lines 130 - 135, The call to
switchTo(Organization::main()) can pass null and cause a TypeError; update the
super-admin fallback in CurrentOrganization (the block using
Organization::main() and switchTo(Organization $org)) to first assign and guard
the result (e.g., if ($main = Organization::main()) { $this->switchTo($main);
return; } else { /* log error or throw a clear exception */ }), ensuring you
either log a descriptive error or throw a specific exception when main() returns
null instead of calling switchTo with null.

app/Livewire/Forms/UserForm.php-89-114 (1)

89-114: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Returning false on last-super-admin demotion swallows feedback.

update() short-circuits with return false when the only super admin tries to demote themselves, but the form does not surface an error message to the user. Whether the calling Livewire component displays a meaningful failure depends on its boilerplate handling of the boolean. Use addError() (or throw a ValidationException) so the message reliably reaches the UI and the form state stays consistent.

♻️ Proposed fix

         if (auth()->user()->isSuperAdmin()) {
             // Cannot remove the last super admin
             if ($this->user->isSuperAdmin() && ! $this->superAdmin) {
                 if (User::where('super_admin', true)->count() === 1) {
-                    return false;
+                    $this->addError('superAdmin', __('Cannot remove the last super admin.'));
+                    return false;
                 }
             }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Forms/UserForm.php` around lines 89 - 114, The code currently
returns false when preventing the last super admin from being demoted (inside
the auth()->user()->isSuperAdmin() branch checking $this->user->isSuperAdmin()
&& ! $this->superAdmin), which silently fails; replace that return false with a
proper UI-facing error by calling $this->addError('super_admin', 'Cannot remove
the last super admin') (or throw a ValidationException) so the Livewire form
surfaces the message and halts further updates; keep the rest of the update
logic (the $this->user->update(...) calls and the pivot updateExistingPivot on
organizations()) unchanged and ensure you exit the method after adding the
error.

database/factories/UserFactory.php-64-75 (1)

64-75: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Organization::first() may not be the main org.

afterCreating attaches the user to whichever organization happens to come first by primary key, even if it is not flagged is_main. In tests that pre-seed multiple orgs and rely on the user being a member of the main one (e.g. assertions using roleIn(Organization::main())), this can quietly fail. Prefer querying the main org explicitly or fall back to creating one via OrganizationFactory::main().

♻️ Proposed fix

-            $org = Organization::first() ?? Organization::factory()->main()->create();
+            $org = Organization::where('is_main', true)->first()
+                ?? Organization::factory()->main()->create();

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@database/factories/UserFactory.php` around lines 64 - 75, In configure()'s
afterCreating closure, stop using Organization::first() and instead query for
the main organization explicitly (e.g. Organization::where('is_main',
true)->first() or Organization::main()->first()) and if none exists fall back to
Organization::factory()->main()->create(); update the reference to
Organization::first() in the closure to use this main-org lookup so tests that
expect membership in the main org (and the factory method
Organization::factory()->main()) reliably attach the user to the main
organization.

app/Models/Organization.php-104-112 (1)

104-112: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

hasResources() omits sshConfigs from the check, though cascade delete protects them.

SSH configs are deleted when the organization is deleted (via cascadeOnDelete() in the schema), so there's no data loss risk. However, since the method gates the delete button visibility, operators see "no resources" even when SSH configs exist. Include sshConfigs in the check for clarity—so the UI accurately reflects all organization-scoped assets being removed.

♻️ Proposed fix

     public function hasResources(): bool
     {
         return $this->databaseServers()->exists()
             || $this->volumes()->exists()
-            || $this->agents()->exists();
+            || $this->agents()->exists()
+            || $this->sshConfigs()->exists();
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/Organization.php` around lines 104 - 112, The hasResources()
method currently checks databaseServers(), volumes(), and agents() but omits
sshConfigs(), causing the delete UI to report no resources when SSH configs
exist; update hasResources() to also include $this->sshConfigs()->exists()
(i.e., return $this->databaseServers()->exists() || $this->volumes()->exists()
|| $this->agents()->exists() || $this->sshConfigs()->exists()) so the method
reflects all organization-scoped assets.

app/Services/CurrentOrganization.php (1)

44-55: ⚡ Quick win

Reuse User::roleIn() for the current-org lookup.

This method bypasses the eager-loaded/cache-aware path added in User::roleIn(), so userRole() still does a fresh pivot query even when organizations is already loaded. Reusing roleIn($this->organization) keeps a single source of truth and preserves the N+1 fix elsewhere in the PR.

Proposed change

-        $pivot = $user->organizations()->wherePivot('organization_id', $this->organization->id)->first();
-
-        return $pivot?->pivot?->role; // `@phpstan-ignore` property.notFound
+        return $user->roleIn($this->organization);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Services/CurrentOrganization.php` around lines 44 - 55, Replace the
manual pivot lookup in userRole() with the existing User::roleIn() helper to
preserve eager-loaded/cache-aware behavior: obtain the current user (as you
already do), return null if missing, then call
$user->roleIn($this->organization) and return its result instead of performing
the organizations()->wherePivot(...) pivot query; remove the manual pivot access
so userRole() delegates to User::roleIn() as the single source of truth.

app/Livewire/Configuration/Organization.php (1)

44-48: ⚡ Quick win

Only bypass OrganizationScope in these count subqueries.

withoutGlobalScopes() fixes the org-count bug, but it also drops any other global scope those models may gain later. These counts only need to ignore tenant scoping.

Proposed change

+use App\Models\Scopes\OrganizationScope;
...
-            'databaseServers' => fn ($q) => $q->withoutGlobalScopes(),
-            'volumes' => fn ($q) => $q->withoutGlobalScopes(),
-            'agents' => fn ($q) => $q->withoutGlobalScopes(),
+            'databaseServers' => fn ($q) => $q->withoutGlobalScope(OrganizationScope::class),
+            'volumes' => fn ($q) => $q->withoutGlobalScope(OrganizationScope::class),
+            'agents' => fn ($q) => $q->withoutGlobalScope(OrganizationScope::class),

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Configuration/Organization.php` around lines 44 - 48, The count
subqueries on OrganizationModel are calling withoutGlobalScopes(), which removes
all global scopes (risking future scope loss); change each subquery for
'databaseServers', 'volumes', and 'agents' to only remove the tenant
OrganizationScope (e.g., use withoutGlobalScope(OrganizationScope::class)) so
the users/databaseServers/volumes/agents counts bypass only tenant scoping while
preserving other global scopes; locate these calls on
OrganizationModel::withCount([...]) and replace withoutGlobalScopes() with
withoutGlobalScope(OrganizationScope::class).

app/Livewire/Forms/UserForm.php (1)

21-22: ⚡ Quick win

Use the role constants in the validators too.

roleOptions() already derives the allowed values from User::ROLE_*, but the validation rules still hardcode 'viewer,member,admin'. That gives this form two separate definitions of the same contract.

Proposed change

-    #[Validate('required|in:viewer,member,admin')]
+    #[Validate('required|in:'.User::ROLE_VIEWER.','.User::ROLE_MEMBER.','.User::ROLE_ADMIN)]
     public string $role = User::ROLE_MEMBER;
...
-            'role' => 'required|in:viewer,member,admin',
+            'role' => 'required|in:'.User::ROLE_VIEWER.','.User::ROLE_MEMBER.','.User::ROLE_ADMIN,
...
-            'role' => 'required|in:viewer,member,admin',
+            'role' => 'required|in:'.User::ROLE_VIEWER.','.User::ROLE_MEMBER.','.User::ROLE_ADMIN,

Also applies to: 40-44, 63-67

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Forms/UserForm.php` around lines 21 - 22, The Validate attribute
on the $role property hardcodes allowed roles; remove that hardcoded attribute
and move the rule into a dynamic rules() method (or update the existing rules
provider) so it builds the in: list from the source of truth
(User::roleOptions() or the User::ROLE_* constants) — e.g. return ['role' =>
'required|in:' . implode(',', array_values(User::roleOptions()))]; apply the
same change to the other occurrences noted (the other Validate usages at the
referenced blocks) so validation always derives allowed values from User::ROLE_*
rather than a hardcoded string.

app/Livewire/User/Index.php (1)

142-156: ⚡ Quick win

Consolidate redundant org filters and drop whereRaw.

When roleFilter is set, the query emits two EXISTS subqueries on organization_user for the same organization_id — one from whereRelation (line 144) and one from whereHas (line 155). They can be folded into a single whereHas that also covers the role predicate, removing the duplicate EXISTS and the whereRaw.

♻️ Proposed refactor

         $currentOrg = app(CurrentOrganization::class);

-        $query = User::query();
-
-        $query->whereRelation('organizations', 'organization_id', $currentOrg->id());
-
-        $users = $query
+        $users = User::query()
             ->with('organizations')
+            ->whereHas('organizations', function ($q) use ($currentOrg) {
+                $q->where('organization_id', $currentOrg->id());
+                if ($this->roleFilter !== '') {
+                    $q->where('role', $this->roleFilter);
+                }
+            })
             ->when($this->search, function ($query) {
                 $query->where(function ($q) {
                     $q->where('name', 'like', '%'.$this->search.'%')
                         ->orWhere('email', 'like', '%'.$this->search.'%');
                 });
             })
-            ->when($this->roleFilter !== '', function ($query) use ($currentOrg) {
-                $query->whereHas('organizations', fn ($q) => $q->whereRaw('organization_id = ? and role = ?', [$currentOrg->id(), $this->roleFilter]));
-            })
             ->when($this->statusFilter !== '', function ($query) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/User/Index.php` around lines 142 - 156, Remove the initial
whereRelation call and consolidate the organization filter into the existing
whereHas on the organizations relation: use User::query()->when($this->search,
...)->whereHas('organizations', function($q) use ($currentOrg) {
$q->where('organization_id', $currentOrg->id()); if ($this->roleFilter !== '') {
$q->where('role', $this->roleFilter); } }); this removes the duplicate EXISTS
and replaces whereRaw with explicit where(...) calls on the organizations
relation (keep the ->with('organizations') and existing search logic intact).

tests/Feature/User/CreateTest.php (1)

59-79: 💤 Low value

Nit: import Organization instead of repeating the FQN.

\App\Models\Organization is referenced three times (lines 59, 67, 78). A use statement at the top would match the convention used in tests/Feature/Configuration/OrganizationTest.php (which aliases it as OrganizationModel).

♻️ Proposed cleanup

 use App\Livewire\User\Create;
+use App\Models\Organization;
 use App\Models\User;
 use Livewire\Livewire;
@@
-    expect($user->roleIn(\App\Models\Organization::main()))->toBe('member');
+    expect($user->roleIn(Organization::main()))->toBe('member');
@@
-    $otherOrg = \App\Models\Organization::factory()->create();
+    $otherOrg = Organization::factory()->create();
@@
-    expect($existingUser->roleIn(\App\Models\Organization::main()))->toBe('viewer');
+    expect($existingUser->roleIn(Organization::main()))->toBe('viewer');

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/User/CreateTest.php` around lines 59 - 79, Import the
Organization model at the top and replace the three FQN usages to match the
project convention; add a use statement for App\Models\Organization (or alias it
as OrganizationModel to follow OrganizationTest) and change the three
occurrences of \App\Models\Organization::main() in the CreateTest Livewire test
to Organization::main() (or OrganizationModel::main() if aliased) so the test
uses the imported symbol instead of the fully-qualified names.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

resources/views/livewire/user/create.blade.php (1)

60-74: 💤 Low value

Duplicate role label rendered on the group.

Both blocks render a manual <label> ("Role in current organization") immediately followed by <x-radio-card-group ... :label="__('Role')">, which causes the component to render its own internal "Role" label as well. Drop one of them so only a single, clear label is shown.

♻️ Proposed fix

-                <div>
-                    <label class="label label-text font-semibold mb-2">{{ __('Role in current organization') }}</label>
-                    <x-radio-card-group class="grid-cols-1 sm:grid-cols-3" :label="__('Role')">
+                <div>
+                    <x-radio-card-group class="grid-cols-1 sm:grid-cols-3" :label="__('Role in current organization')">

Also applies to: 93-107

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@resources/views/livewire/user/create.blade.php` around lines 60 - 74, The UI
renders two labels for the role field because a manual <label> element is placed
immediately before the <x-radio-card-group> which also outputs its own label via
the :label prop; remove one to avoid duplicate text—either delete the manual
<label class="label label-text...">{{ __('Role in current organization')
}}</label> or remove the :label="__('Role')" prop on the <x-radio-card-group>
component (same change must be applied in the duplicate block near the bottom of
the file that mirrors this role field).

app/Livewire/User/Index.php (1)

147-161: 💤 Low value

Consolidate the org + role filter into one whereHas and drop whereRaw.

As written, you produce two independent EXISTS subqueries against organization_user (one from whereRelation, another from whereHas when roleFilter is set), and the role-filter branch uses raw SQL where it isn't needed. Both filters target the same pivot relationship and can be expressed once with a parameterised where:

♻️ Proposed fix

-        $query = User::query();
-
-        $query->whereRelation('organizations', 'organization_id', $currentOrg->id());
-
-        $users = $query
-            ->with('organizations')
+        $orgId = $currentOrg->id();
+
+        $users = User::query()
+            ->with('organizations')
+            ->whereHas('organizations', function ($q) use ($orgId) {
+                $q->where('organization_id', $orgId);
+            })
             ->when($this->search, function ($query) {
                 $query->where(function ($q) {
                     $q->where('name', 'like', '%'.$this->search.'%')
                         ->orWhere('email', 'like', '%'.$this->search.'%');
                 });
             })
-            ->when($this->roleFilter !== '', function ($query) use ($currentOrg) {
-                $query->whereHas('organizations', fn ($q) => $q->whereRaw('organization_id = ? and role = ?', [$currentOrg->id(), $this->roleFilter]));
-            })
+            ->when($this->roleFilter !== '', function ($query) use ($orgId) {
+                $query->whereHas('organizations', fn ($q) => $q
+                    ->where('organization_id', $orgId)
+                    ->where('role', $this->roleFilter));
+            })

Note: the outer whereHas and the role-scoped whereHas still produce two EXISTS subqueries. If you want a single one, you can keep only the role-scoped variant and make it the always-applied org filter, switching to where('role', $this->roleFilter) only when set.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/User/Index.php` around lines 147 - 161, Replace the separate
whereRelation + conditional whereHas with a single whereHas on the
'organizations' relation: remove the call to whereRelation('organizations', ...)
and instead call whereHas('organizations', function($q) use ($currentOrg) {
$q->where('organization_id', $currentOrg->id()); if ($this->roleFilter !== '') {
$q->where('role', $this->roleFilter); } }); — this drops the raw SQL, keeps the
organization filter and only applies the role filter when set, preserving the
existing with('organizations') and search logic.

tests/Feature/User/CreateTest.php (1)

87-115: ⚡ Quick win

Test relies on implicit factory side-effect (attachment to Main org).

Both tests assume User::factory()->create() attaches the new user to Organization::main() by default — line 92-94 deliberately syncs to a different org to remove that membership, while line 105-115 relies on it to assert "already a member". This implicit dependency on factory behaviour is fragile; if the default attachment ever changes, both tests will fail in non-obvious ways.

Consider making the membership state explicit at the start of each test (e.g., explicitly attach/detach in arrange) to document the precondition.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/User/CreateTest.php` around lines 87 - 115, The tests for the
Create Livewire component rely on User::factory()->create() implicitly attaching
users to Organization::main(); make the membership explicit: in the "admin can
add existing user" test ensure the created $existingUser is detached from
Organization::main() (e.g., call
$existingUser->organizations()->detach(Organization::main()->id) or sync to the
other org) before calling Livewire::test(Create::class), and in the "rejects
adding user already in organization" test explicitly attach the $existingUser to
Organization::main() with the expected role (e.g.,
$existingUser->organizations()->attach(Organization::main()->id, ['role' =>
'member'])) so the preconditions for Create::addExisting and the
roleIn(Organization::main()) assertions are obvious and stable.

tests/Feature/User/EditTest.php (1)

51-57: 💤 Low value

Prefer factory states over ['role' => $role] for consistency.

Same pattern as IndexTest::non-admin cannot access user index: the dataset values 'member' / 'viewer' correspond to existing factory states used elsewhere in this PR. Switching to User::factory()->{$state}()->create() ensures the per-organization pivot role is set in addition to the legacy column.

As per coding guidelines: "Check if the factory has custom states before manually setting up the model."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/User/EditTest.php` around lines 51 - 57, The test currently
creates non-admin users with User::factory()->create(['role' => $role]) which
bypasses factory states and misses per-organization pivot role; update the test
'non-admin cannot edit users' to use the factory states instead (e.g.
User::factory()->member()->create() and User::factory()->viewer()->create()) so
the per-organization pivot role is set correctly; keep the rest of the test (the
actingAs($user) call and get(route('users.edit', $target))->assertForbidden())
unchanged and ensure the ->with([...]) data provider values match the state
method names.

resources/views/livewire/configuration/organization.blade.php (1)

12-12: 💤 Low value

Add rel="noopener noreferrer" to external _blank link.

External link with target="_blank" should set rel="noopener noreferrer" to prevent the opened tab from accessing window.opener and to avoid leaking the referrer.

♻️ Proposed fix

-        <a href="https://david-crty.github.io/databasement/docs/user-guide/organizations" target="_blank" class="link link-primary">{{ __('Learn more') }}</a>
+        <a href="https://david-crty.github.io/databasement/docs/user-guide/organizations" target="_blank" rel="noopener noreferrer" class="link link-primary">{{ __('Learn more') }}</a>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@resources/views/livewire/configuration/organization.blade.php` at line 12,
The external anchor tag rendering the "Learn more" link uses target="_blank" but
is missing rel="noopener noreferrer"; update the <a> element in the organization
Blade view (the anchor with class "link link-primary" and text "Learn more") to
include rel="noopener noreferrer" so the new tab cannot access window.opener and
the referrer is not leaked.

app/Livewire/User/Create.php (1)

53-56: ⚡ Quick win

Keep the existing-user rules on the component or form object.

addExisting() adds another inline rule array even though this component already uses UserForm for the invite flow. Please move existingUserId / existingUserRole to #[Validate] attributes or a form object so both modes follow the same Livewire pattern.

As per coding guidelines: "In Livewire components, use #[Validate] attributes or Form objects for validation. Call $this->validate() before processing data."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/User/Create.php` around lines 53 - 56, The inline validation for
existingUserId and existingUserRole inside the Livewire component should be
moved to the component's validation declarations instead of calling
$this->validate() with an ad-hoc array in addExisting(); update the component to
use #[Validate] attributes or include these fields on the existing UserForm so
both invite and addExisting() flows reuse the same rules (reference
existingUserId, existingUserRole, addExisting(), UserForm and #[Validate]) and
remove the duplicate inline rule array so validation follows the Livewire
form/attribute pattern.

app/Livewire/Configuration/Organization.php (2)

76-76: ⚡ Quick win

Use Livewire navigate redirects after these actions.

These plain redirects force a full page load. Prefer $this->redirect(..., navigate: true) here so organization CRUD stays consistent with the app’s SPA-style navigation.

↪️ Minimal change

-        return $this->redirect(route('configuration.organizations'));
+        return $this->redirect(route('configuration.organizations'), navigate: true);

As per coding guidelines: "In Livewire components, return $this->redirect() with navigate: true for SPA-like navigation."

Also applies to: 105-105, 129-129

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Configuration/Organization.php` at line 76, The redirect calls
in the Livewire component Organization.php perform full page loads; replace each
plain redirect call (the return
$this->redirect(route('configuration.organizations')) instances at the three
spots) with Livewire navigation-enabled redirects by calling
$this->redirect(..., navigate: true) so the component uses SPA-style navigation;
update the redirect invocations in the methods that currently return redirects
(the Organization Livewire action methods around the redirect lines)
accordingly.

---

65-67: ⚡ Quick win

Move these organization-name rules into Livewire state.

Both actions define ad-hoc validation arrays inside the methods. Please keep newOrgName / editOrgName on #[Validate] attributes or a small form object so this component follows the repo’s Livewire validation pattern.

As per coding guidelines: "In Livewire components, use #[Validate] attributes or Form objects for validation. Call $this->validate() before processing data."

Also applies to: 96-98

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Configuration/Organization.php` around lines 65 - 67, The inline
validation arrays for newOrgName (and similarly editOrgName) should be moved out
of the method and defined as Livewire validation metadata — add #[Validate]
attributes (or a small Form object) on the Organization component properties
newOrgName and editOrgName with the rules
'required|string|max:255|unique:organizations,name' (and the corresponding edit
rule), then remove the ad-hoc arrays from the methods (at lines calling
$this->validate([...])) so the methods simply call $this->validate() to trigger
the attribute-based validation; update any references in the create/edit
handlers to rely on the validated properties.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

resources/views/livewire/user/create.blade.php (1)

51-57: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Move the super-admin authorization check into the Livewire component

Line 51 calls auth()->user()->isSuperAdmin() directly in the Blade view. Expose a component property (e.g., $isSuperAdmin) and render with @if($isSuperAdmin) so the template stays presentation-only.

♻️ Proposed fix

-                `@if`(auth()->user()->isSuperAdmin())
+                `@if`($isSuperAdmin)
                     <x-checkbox
                         wire:model="form.superAdmin"
                         :label="__('Super Admin')"
                         :hint="__('Super admins can access all organizations and manage global settings.')"
                     />
                 `@endif`

// app/Livewire/User/Create.php
public bool $isSuperAdmin = false;

public function mount(): void
{
    $this->isSuperAdmin = auth()->user()->isSuperAdmin();
}

As per coding guidelines: "All Livewire component blade files should contain only view markup; all PHP logic must be in the component class."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@resources/views/livewire/user/create.blade.php` around lines 51 - 57, The
Blade view is calling auth()->user()->isSuperAdmin() directly; move that logic
into the Livewire component by adding a public bool property $isSuperAdmin on
the User\Create component (e.g., class Create) and set it in mount():
$this->isSuperAdmin = auth()->user()->isSuperAdmin(); then update the view to
use `@if`($isSuperAdmin) instead of auth()->user()->isSuperAdmin() so the template
remains presentation-only.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/Livewire/Configuration/Organization.php (1)

23-29: ⚡ Quick win

Move the shared field rules onto the Livewire properties.

These inline rule arrays work, but they bypass the repo’s Livewire validation pattern and duplicate the non-unique parts of the rules. Put the shared required|string|max:255 checks on $newOrgName / $editOrgName with #[Validate] (or a small Form object), then keep only the action-specific unique rule inline.

♻️ Minimal refactor

 use Livewire\Attributes\Computed;
 use Livewire\Attributes\Title;
+use Livewire\Attributes\Validate;
 use Livewire\Component;
@@
-    public string $newOrgName = '';
+    #[Validate('required|string|max:255')]
+    public string $newOrgName = '';
@@
-    public string $editOrgName = '';
+    #[Validate('required|string|max:255')]
+    public string $editOrgName = '';
@@
         $this->validate([
-            'newOrgName' => 'required|string|max:255|unique:organizations,name',
+            'newOrgName' => 'unique:organizations,name',
         ]);
@@
         $this->validate([
-            'editOrgName' => 'required|string|max:255|unique:organizations,name,'.$org->id,
+            'editOrgName' => 'unique:organizations,name,'.$org->id,
         ]);

As per coding guidelines: "In Livewire components, use #[Validate] attributes or Form objects for validation. Call $this->validate() before processing data."

Also applies to: 67-69, 100-102

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Configuration/Organization.php` around lines 23 - 29, Move the
common "required|string|max:255" validation onto the Livewire properties by
adding the #[Validate] attribute for $newOrgName and $editOrgName (or replace
with a small Form object) so those checks are centralized; then remove those
parts from the inline rule arrays in the create/update actions and leave only
the action-specific "unique" constraint inline (e.g., in the methods that
currently reference editingOrgId or create org); finally ensure each action
calls $this->validate() before processing so validation runs.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/Livewire/User/Edit.php-47-47 (1)

47-47: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

auth()->user() is statically nullable — add null-safe operator.

auth()->user() returns Authenticatable|null. Calling ->isSuperAdmin() directly will throw if the user is somehow unauthenticated during a re-render (e.g. expired session with an in-flight Livewire request).

🛡️ Proposed fix

-            'isSuperAdmin' => auth()->user()->isSuperAdmin(),
+            'isSuperAdmin' => auth()->user()?->isSuperAdmin() ?? false,

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/User/Edit.php` at line 47, The code passes
auth()->user()->isSuperAdmin() without guarding for a null user; change the
expression to use the null-safe operator and a default boolean, e.g.
auth()->user()?->isSuperAdmin() ?? false, so the 'isSuperAdmin' value is always
a boolean and won't throw if auth()->user() is null; update the array entry
where 'isSuperAdmin' is set to use this null-safe expression (replace the direct
call to isSuperAdmin()).

tests/Feature/Mcp/McpServerTest.php-196-196 (1)

196-196: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Organization::first() without a null guard can throw in isolated test runs.

If the test database contains no organizations when this line executes, Organization::first() returns null and PHP will throw on ->id. The VolumeFactory in this same PR correctly uses Organization::first()?->id with a fallback. Apply the same defensive pattern here (and at line 259).

✏️ Proposed fix (lines 196 and 259)

-        'organization_id' => \App\Models\Organization::first()->id,
+        'organization_id' => \App\Models\Organization::first()?->id
+            ?? \App\Models\Organization::factory()->main()->create()->id,

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Mcp/McpServerTest.php` at line 196, The test sets
'organization_id' using Organization::first()->id which will crash if no
Organization exists; change the assignment to use the null-safe operator and a
fallback like Organization::first()?->id ??
Organization::factory()->create()->id so it returns an existing id or creates
one; apply the same change to the other occurrence referenced in the review (the
second 'organization_id' assignment).

tests/Feature/DatabaseServer/SshTunnelTest.php-20-21 (1)

20-21: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use Organization::main() instead of Organization::first() to avoid null dereference.

This file uses RefreshDatabase, so Organization::first() returns null if no org seeder runs, causing a fatal TypeError on ->id. Other tests in this PR (e.g., SnapshotsCardTest line 98) consistently use Organization::main(), which provides a guaranteed non-null result.

✏️ Proposed fix (apply to all 4 occurrences)

-'organization_id' => \App\Models\Organization::first()->id,
+'organization_id' => \App\Models\Organization::main()->id,

Also applies to: 69-70, 113-114, 195-196

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/DatabaseServer/SshTunnelTest.php` around lines 20 - 21, Replace
all uses of Organization::first() in
tests/Feature/DatabaseServer/SshTunnelTest.php with Organization::main() to
avoid null dereference under RefreshDatabase; specifically update the four
occurrences where code builds test data (the array entries using
'organization_id' => \App\Models\Organization::first()->id) so they call
\App\Models\Organization::main()->id instead, ensuring a guaranteed non-null
Organization instance is returned for the tests.

tests/Feature/Volume/VolumeTest.php-207-208 (1)

207-208: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Same Organization::first() null-dereference risk as SshTunnelTest.php.

All seven Volume::create([..., 'organization_id' => \App\Models\Organization::first()->id]) calls are subject to a TypeError if no organization row exists when the test runs. Replace with Organization::main()->id to match the safe accessor used elsewhere in this PR.

✏️ Proposed fix (apply to all 7 occurrences)

-'organization_id' => \App\Models\Organization::first()->id,
+'organization_id' => \App\Models\Organization::main()->id,

Also applies to: 213-214, 230-231, 236-237, 254-255, 408-409, 452-453

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Volume/VolumeTest.php` around lines 207 - 208, Replace the
unsafe Organization::first()->id usage in the Volume::create calls with the safe
accessor Organization::main()->id; locate each Volume::create([...
'organization_id' => \App\Models\Organization::first()->id]) occurrence (seven
total) and change the organization_id expression to
\App\Models\Organization::main()->id so it no longer risks a null-dereference at
runtime.

app/Livewire/Settings/TwoFactor.php-46-49 (1)

46-49: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Stale inline comment — update to match the broadened isOAuth() check.

The comment says "OAuth-only users" but the predicate was widened from isOAuthOnly() to isOAuth(), which now covers all OAuth-linked accounts regardless of whether they also have a password. The user-facing message on line 48 already reflects the correct intent; the inline comment should be updated to match.

✏️ Proposed fix

-        // OAuth-only users don't have a password to use 2FA
+        // OAuth users authenticate via their provider and should not configure app-level 2FA
         if (Auth::user()->isOAuth()) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Settings/TwoFactor.php` around lines 46 - 49, Update the stale
inline comment above the Auth::user()->isOAuth() check in the TwoFactor Livewire
component to reflect that the predicate now applies to all OAuth-linked accounts
(not just OAuth-only users); replace "OAuth-only users don't have a password to
use 2FA" with a concise note like "OAuth-linked accounts may not be eligible for
2FA" or similar so the comment matches the widened isOAuth() semantics.

config/oauth.php-24-24 (1)

24-24: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Env var name breaks the OAUTH_OIDC_* naming convention.

Every other OIDC-specific setting in this file follows the OAUTH_OIDC_ prefix (OAUTH_OIDC_ENABLED, OAUTH_OIDC_CLIENT_ID, OAUTH_OIDC_ROLE_CLAIM, etc.). The new variable OIDC_DEFAULT_ORGANIZATION_ID is the only exception, which complicates discoverability for operators configuring the SSO block. Consider renaming to OAUTH_OIDC_DEFAULT_ORGANIZATION_ID and updating the corresponding documentation.

✏️ Proposed fix

-'default_organization_id' => env('OIDC_DEFAULT_ORGANIZATION_ID'),
+'default_organization_id' => env('OAUTH_OIDC_DEFAULT_ORGANIZATION_ID'),

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@config/oauth.php` at line 24, The env var used for default_organization_id
breaks the OAUTH_OIDC_* convention; change the env key used in the config entry
default_organization_id to read from env('OAUTH_OIDC_DEFAULT_ORGANIZATION_ID')
instead of env('OIDC_DEFAULT_ORGANIZATION_ID'), and update any docs/config
examples that reference the old OIDC_DEFAULT_ORGANIZATION_ID name to the new
OAUTH_OIDC_DEFAULT_ORGANIZATION_ID so operators can discover it consistently
with other OAUTH_OIDC_* settings.

docs/docs/self-hosting/configuration/sso.md-141-149 (1)

141-149: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

OIDC_DEFAULT_ORGANIZATION_ID is missing from the Environment Variables Reference table and its OIDC_ prefix is misleading for non-OIDC OAuth providers.

Two issues:

1. The variable is not listed in the "Environment Variables Reference" table (lines 228–235), which only covers the OIDC role-mapping variables. Users scanning that table won't find it.
2. The OIDC_ prefix (vs. the OAUTH_ prefix used by all other user-creation settings like OAUTH_DEFAULT_ROLE, OAUTH_AUTO_CREATE_USERS) implies this applies only to the Generic OIDC provider, but the description says it affects all auto-created OAuth users. This could cause Google/GitHub/GitLab OAuth users to overlook it.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/docs/self-hosting/configuration/sso.md` around lines 141 - 149, The docs
omit OIDC_DEFAULT_ORGANIZATION_ID from the "Environment Variables Reference"
table and its OIDC_ prefix misleads readers — add an entry for the
organization-default env var to that table and change the documented variable
name to OAUTH_DEFAULT_ORGANIZATION_ID (or clearly state that
OIDC_DEFAULT_ORGANIZATION_ID is an alias and mark it deprecated) so it matches
other user-creation vars like OAUTH_DEFAULT_ROLE and OAUTH_AUTO_CREATE_USERS;
update the prose in the "Default Organization" section to mention the canonical
name OAUTH_DEFAULT_ORGANIZATION_ID (and any alias handling) and ensure the table
row includes a short description and example ULID.

app/Models/BackupJob.php-78-92 (1)

78-92: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add isResolved() guard before calling id() to match OrganizationScope's pattern — and check Snapshot.php for the same issue.

OrganizationScope::apply() guards id() with isResolved() because CurrentOrganization::$organization is nullable and id() directly accesses it without checks. Calling id() without the guard will throw "Call to a member function id() on null" in CLI contexts, queue workers, and tests without org setup.

Both BackupJob::scopeForCurrentOrg() (line 80) and Snapshot::scopeForCurrentOrg() (line 204) have the same unguarded call.

🛡️ Proposed fix

 public function scopeForCurrentOrg(Builder $query): Builder
 {
-    $orgId = app(CurrentOrganization::class)->id();
+    $currentOrg = app(CurrentOrganization::class);
+
+    if (! $currentOrg->isResolved()) {
+        return $query->whereRaw('0 = 1'); // No org context → no results
+    }
+
+    $orgId = $currentOrg->id();

     return $query->where(function (Builder $q) use ($orgId) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/BackupJob.php` around lines 78 - 92, The scopeForCurrentOrg
methods call app(CurrentOrganization::class)->id() without checking if the
current organization is resolved; add a guard using
app(CurrentOrganization::class)->isResolved() and only call id() when true to
avoid null dereference. Update BackupJob::scopeForCurrentOrg (and mirror the
same change in Snapshot::scopeForCurrentOrg) to first get the
CurrentOrganization instance, check isResolved(), and if not resolved return the
query unmodified (or apply no organization filter), otherwise obtain id() and
proceed with the whereHas/withoutGlobalScope logic.

resources/views/livewire/settings/delete-user-form.blade.php-27-32 (1)

27-32: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use :label dynamic binding for translated strings passed to component attributes.

Lines 27, 31, and 32 pass translated strings via {{ __() }} interpolation. This double-encodes HTML entities in translations.

♻️ Proposed fix

-            <x-password wire:model="password" label="{{ __('Password') }}" />
+            <x-password wire:model="password" :label="__('Password')" />
 
             <div class="flex justify-end gap-2">
-                <x-button label="{{ __('Cancel') }}" `@click`="$wire.showDeleteModal = false" />
-                <x-button label="{{ __('Delete account') }}" class="btn-error" type="submit" data-test="confirm-delete-user-button" />
+                <x-button :label="__('Cancel')" `@click`="$wire.showDeleteModal = false" />
+                <x-button :label="__('Delete account')" class="btn-error" type="submit" data-test="confirm-delete-user-button" />
             </div>

As per coding guidelines: "In Blade templates, use :attr binding (dynamic syntax) instead of {{ }} interpolation when passing translated strings to component attributes to avoid double-encoding special characters."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@resources/views/livewire/settings/delete-user-form.blade.php` around lines 27
- 32, The Blade template is passing translated strings into component attributes
using interpolation (e.g., label="{{ __('Password') }}", label="{{ __('Cancel')
}}", label="{{ __('Delete account') }}"), which can double-encode entities;
update the component attribute bindings to use dynamic binding syntax (use
:label) and pass the translation directly (e.g., :label="__('Password')" etc.)
for the <x-password> and both <x-button> components (preserve other attributes
like class, type, data-test unchanged).

app/Http/Middleware/DemoModeMiddleware.php-55-68 (1)

55-68: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Organization::main() is not null-safe — a missing main org crashes the demo login page.

If Organization::main() returns null (main org deleted, or demo mode enabled before migrations have run), ->id on line 67 throws a fatal error, making the login page completely inaccessible. ensureDemoUserExists() is designed to be self-sufficient; mirror the firstOrCreate pattern already used in CreateNewUser.php:

🛡️ Proposed fix

-        $user->organizations()->syncWithoutDetaching([
-            Organization::main()->id => ['role' => UserRole::Demo->value],
-        ]);
+        $mainOrg = Organization::firstOrCreate(
+            ['is_main' => true],
+            ['name' => 'Main']
+        );
+
+        $user->organizations()->syncWithoutDetaching([
+            $mainOrg->id => ['role' => UserRole::Demo->value],
+        ]);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Http/Middleware/DemoModeMiddleware.php` around lines 55 - 68,
ensureDemoUserExists() assumes Organization::main() is non-null and calling ->id
crashes if main org is missing; update the method to retrieve or create a main
organization first (mirror the firstOrCreate pattern used in CreateNewUser.php)
by calling Organization::firstOrCreate(...) with the same identifying attributes
used for the main org, then use the returned Organization object's id when
calling $user->organizations()->syncWithoutDetaching(...). Ensure you reference
Organization::main() fallback to the newly created Organization so the demo user
setup is self-sufficient if the main org is absent.

tests/Feature/Settings/TwoFactorAuthenticationTest.php-31-38 (1)

31-38: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Keep a local password on this fixture so the test covers the new gate.

A passwordless OAuth account would also pass the old “OAuth-only” check, so this setup won’t catch a regression back to that behavior. Leaving the normal password in place and only adding the OAuthIdentity makes the assertion prove the broader block.

Suggested change

-test('oauth user is blocked from two factor settings', function () {
-    $user = User::factory()->create(['password' => null]);
+test('oauth user is blocked from two factor settings', function () {
+    $user = User::factory()->create();
     OAuthIdentity::create([
         'user_id' => $user->id,
         'provider' => 'github',

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Settings/TwoFactorAuthenticationTest.php` around lines 31 - 38,
The test "oauth user is blocked from two factor settings" creates a passwordless
user which doesn't exercise the new gate; instead keep a local password on the
fixture by removing the ['password' => null] override (or explicitly set a
hashed password via Hash::make) when calling User::factory()->create(), then
attach the OAuthIdentity as before so the test proves an account with both a
local password and an OAuthIdentity is blocked by the new gate.

docs/docs/user-guide/organizations.md-67-73 (1)

67-73: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use the implemented org query parameter in the API examples.

This section documents ?org_id=, but the PR wiring and manual verification use ?org=. Following the current example will make org scoping look broken to API users.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/docs/user-guide/organizations.md` around lines 67 - 73, The docs
currently show the query parameter as ?org_id= but the implementation and tests
expect ?org=; update the example and surrounding text to use the implemented
parameter (?org=01JA2B3C4D5E6F7G8H9J0KMNPQ) and confirm the alternate header
(X-Organization-Id) wording remains accurate; ensure any mentions of org_id in
this paragraph are replaced with org so the example in the GET
/api/v1/database-servers request and the explanatory sentence match the actual
behavior.

app/Livewire/User/Create.php-101-105 (1)

101-105: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Clarify the scope and semantics of hasMultipleOrganizations().

This computed property checks the global organization count (Organization::count() > 1), but the method name suggests it checks user-specific organizations. Since the component operates in a single-organization context (gating org-specific UI for "this organization"), either:

1. Rename to platformHasMultipleOrganizations() if the intent is to check whether the platform is multi-tenant, or
2. Change the implementation to auth()->user()->organizations()->count() > 1 if the intent is to check whether the current user belongs to multiple organizations.

The current naming is ambiguous and the implementation may not match the intended use case.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/User/Create.php` around lines 101 - 105, The computed property
hasMultipleOrganizations() currently returns Organization::count() > 1 which
checks platform-wide orgs but its name implies a user-scoped check; either
rename the method to platformHasMultipleOrganizations() and keep the
Organization::count() > 1 logic, or change its implementation to use the current
user’s org membership (auth()->user()->organizations()->count() > 1) and keep
the name hasMultipleOrganizations(); update any callers to match the chosen
name/semantics (e.g., replace usages of hasMultipleOrganizations with
platformHasMultipleOrganizations if you rename it).

app/Models/User.php-205-208 (1)

205-208: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix the return type annotation on CurrentOrganization::model() to accurately reflect that the organization can be null.

The middleware guarantees that requests with an unresolved organization are rejected before reaching code that calls currentOrgRole(), so currentOrgRole() is safe in practice. However, model() is annotated to return Organization (non-nullable) while the property $organization is private ?Organization $organization = null. This type mismatch is misleading for static analysis and future maintainers.

The return type should be ?Organization to match the actual property type and the initialization state:

 /**
  * Get the current organization model.
  */
-public function model(): Organization
+public function model(): ?Organization
 {
     return $this->organization;
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/User.php` around lines 205 - 208, Change the return type of
CurrentOrganization::model() from Organization to ?Organization to reflect the
actual nullable property $organization; update the method signature and any
associated docblock/PhpDoc in the CurrentOrganization class so static analysis
matches runtime behavior, and ensure callers like User::currentOrgRole() (which
calls app(\App\Services\CurrentOrganization::class)->model()) are satisfied by
the nullable return type (adjust any strict type hints or null checks where
necessary).

resources/views/livewire/organization-switcher.blade.php (1)

6-7: 💤 Low value

Redundant wire:model + wire:change causes two Livewire round-trips per selection

On <select> elements, Livewire binds wire:model to the change event — the same event wire:change uses. Every org switch triggers two concurrent requests: one to update currentOrgId, one to call switchOrg().

Consider one of the canonical Livewire patterns instead:

• Option A — keep wire:model, drop wire:change, add updatedCurrentOrgId($value) in the component class.
• Option B — keep wire:change only; set the initial selected state via a :value binding on the component.

♻️ Option A (component-class hook)

-        wire:model="currentOrgId"
-        wire:change="switchOrg($event.target.value)"
+        wire:model="currentOrgId"

Then in App\Livewire\OrganizationSwitcher:

public function updatedCurrentOrgId(string $value): void
{
    $this->switchOrg($value);
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@resources/views/livewire/organization-switcher.blade.php` around lines 6 - 7,
The select currently uses both wire:model="currentOrgId" and
wire:change="switchOrg($event.target.value)", causing duplicate Livewire
requests; pick one pattern and remove the other. Either keep
wire:model="currentOrgId" and remove wire:change, then add an
updatedCurrentOrgId(string $value) method in the
App\Livewire\OrganizationSwitcher class that calls switchOrg($value), or remove
wire:model and keep wire:change="switchOrg($event.target.value)" and ensure the
initial selected option is set from the component state (currentOrgId) so UI
reflects the active org. Update the select and the OrganizationSwitcher
component accordingly.

resources/views/livewire/settings/profile.blade.php (1)

11-11: 💤 Low value

Use :attr binding for the translated label to match project convention.

label="{{ __('Email') }}" passes a translated string via Blade echo. Per the coding guideline, pass translated strings to component attributes with : dynamic binding to avoid double-encoding issues in non-ASCII locales.

✏️ Proposed fix

-               label="{{ __('Email') }}"
+               :label="__('Email')"

As per coding guidelines: "In Blade templates, use :attr binding (dynamic syntax) instead of {{ }} interpolation when passing translated strings to component attributes to avoid double-encoding special characters."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@resources/views/livewire/settings/profile.blade.php` at line 11, The label
attribute is using Blade echo which can double-encode translated text; update
the component attribute from label="{{ __('Email') }}" to use dynamic binding
:label="__('Email')" so the translated string is passed directly (look for the
label attribute on the input/component in profile.blade.php and replace the
quoted Blade interpolation with the :label dynamic binding).

tests/Feature/Mcp/McpServerTest.php (1)

98-98: ⚡ Quick win

Use viewer() factory state to match the approach adopted in other test files.

DatabaseServerCrudApiTest.php was explicitly migrated from create(['role' => 'viewer']) to User::factory()->viewer()->create() as part of this PR. The same tests here were only half-updated (value changed to UserRole::Viewer enum, but the attribute-override approach retained). If the role column is eventually removed from users in favour of the org pivot exclusively, this test will silently create a non-viewer user and the authorization assertion will pass for the wrong reasons.

✏️ Proposed fix (lines 98 and 144)

-    $user = User::factory()->create(['role' => UserRole::Viewer]);
+    $user = User::factory()->viewer()->create();

As per coding guidelines: "When creating models for tests, use factories. Check if the factory has custom states before manually setting up the model."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Mcp/McpServerTest.php` at line 98, Replace the manual role
override when creating test users with the factory state to ensure the created
user has the viewer traits; specifically change the creation in McpServerTest
from using User::factory()->create(['role' => UserRole::Viewer]) to using the
viewer factory state (User::factory()->viewer()->create()) so the test relies on
the factory's viewer configuration rather than directly setting the role column;
update any other occurrences in this file (e.g., the second creation at line
~144) to the same pattern to prevent future drift if the role column is removed.

resources/views/livewire/configuration/_tabs.blade.php (1)

18-23: ⚡ Quick win

Move isSuperAdmin() check to the component class.

Calling auth()->user()->isSuperAdmin() inside a Livewire blade partial introduces PHP logic that should live in the component. This also creates a latent null-dereference if auth()->user() ever returns null (e.g., middleware misconfiguration).

✏️ Proposed fix

In the hosting Livewire component(s) that include this partial, expose the flag:

// e.g., app/Livewire/Configuration/SomePage.php
public bool $showOrganizationsTab = false;

public function mount(): void
{
    $this->showOrganizationsTab = auth()->user()?->isSuperAdmin() ?? false;
}

Then in the partial:

-    `@if`(auth()->user()->isSuperAdmin())
+    `@if`($showOrganizationsTab)
         <a href="{{ route('configuration.organizations') }}" wire:navigate
            role="tab" `@class`(['tab', 'tab-active' => $active === 'organizations'])>
             {{ __('Organizations') }}
         </a>
     `@endif`

As per coding guidelines: "All Livewire component blade files should contain only view markup; all PHP logic must be in the component class."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@resources/views/livewire/configuration/_tabs.blade.php` around lines 18 - 23,
Move the isSuperAdmin() check out of the blade and into the Livewire component:
add a public bool property (e.g., showOrganizationsTab) to the hosting component
class and set it in mount() using a null-safe check on auth()->user() (e.g.,
auth()->user()?->isSuperAdmin() ?? false) so you avoid null dereference; then
update the partial to use `@if`($showOrganizationsTab) instead of calling
auth()->user()->isSuperAdmin() directly.

app/Livewire/Forms/VolumeForm.php (1)

99-107: 💤 Low value

Inline organization_id directly into $data for cleaner construction.

The two-step build (array literal + separate append) is functionally equivalent but slightly harder to scan at a glance.

✏️ Proposed refactor

-        $data = [
-            'name' => $this->name,
-            'type' => $this->type,
-            'config' => $this->buildConfig(),
-        ];
-
-        $data['organization_id'] = app(CurrentOrganization::class)->id();
-
-        Volume::create($data);
+        Volume::create([
+            'name'            => $this->name,
+            'type'            => $this->type,
+            'config'          => $this->buildConfig(),
+            'organization_id' => app(CurrentOrganization::class)->id(),
+        ]);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Forms/VolumeForm.php` around lines 99 - 107, The array
construction for creating a Volume is split into an initial $data literal and a
later assignment of organization_id; inline the organization id directly into
the initial $data array to improve readability. Update the block that builds
$data (which currently sets 'name' => $this->name, 'type' => $this->type,
'config' => $this->buildConfig()) to include 'organization_id' =>
app(CurrentOrganization::class)->id(), then call Volume::create($data) as before
so Volume::create, buildConfig, $this->name, $this->type and
app(CurrentOrganization::class)->id() remain unchanged.

tests/Feature/Dashboard/SnapshotsCardTest.php (1)

83-83: ⚡ Quick win

Use User::factory()->admin()->create() instead of manually setting the role attribute.

The UserFactory has a dedicated admin() state (line 93 of database/factories/UserFactory.php) that should be used per coding guidelines. Replace the manual role attribute assignments with the factory state method for consistency and clarity.

Also applies to: 96-96

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Dashboard/SnapshotsCardTest.php` at line 83, Replace manual
role assignment via User::factory()->create(['role' => UserRole::Admin]) with
the factory state helper User::factory()->admin()->create() (and similarly
replace the other occurrence noted) so the test uses the dedicated admin() state
from UserFactory; update the instances in SnapshotsCardTest (where the variable
$admin is created) to call admin() on the factory instead of passing the role
attribute.

app/Models/DatabaseServer.php (1)

22-66: ⚡ Quick win

Missing @property annotations for the new organization_id field and organization relation.

The class-level PHPDoc block doesn't declare the new column or relationship, which breaks IDE type inference and may cause PHPStan to miss type errors in callers that access $server->organization_id or $server->organization.

🔧 Proposed additions

  * `@property` string|null $agent_id
  * `@property` string|null $managed_by
+ * `@property` string $organization_id
  * `@property` NotificationTrigger $notification_trigger
  ...
  * `@property-read` Agent|null $agent
+ * `@property-read` Organization $organization
  * `@property-read` Collection<int, Backup> $backups

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/DatabaseServer.php` around lines 22 - 66, The class PHPDoc for
DatabaseServer is missing annotations for the new organization relationship and
foreign key; update the docblock at the top of the DatabaseServer class to add a
`@property` string|null $organization_id (or correct type) and a `@property-read`
Organization|null $organization entry so IDEs and static analysis (PHPStan)
recognize $server->organization_id and $server->organization; ensure the names
match the actual column and relation method (organization) in the DatabaseServer
model.

tests/Feature/Auth/RegistrationTest.php (1)

29-31: 💤 Low value

Consider importing Organization to avoid the inline FQN.

Line 31 uses \App\Models\Organization::main() as an inline fully-qualified name. Adding a use App\Models\Organization; import at the top keeps it consistent with the file's other model imports.

♻️ Proposed change

+use App\Models\Organization;
 use App\Enums\UserRole;
 use App\Models\DatabaseServer;
 use App\Models\User;

-    expect($user->super_admin)->toBeTrue()
-        ->and($user->roleIn(\App\Models\Organization::main()))->toBe(UserRole::Admin);
+    expect($user->super_admin)->toBeTrue()
+        ->and($user->roleIn(Organization::main()))->toBe(UserRole::Admin);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Auth/RegistrationTest.php` around lines 29 - 31, The test uses
an inline FQN \App\Models\Organization::main() in RegistrationTest (lines
referencing auth()->user() and UserRole::Admin); add a top-level import "use
App\Models\Organization;" and replace the inline FQN with Organization::main()
to match other model imports and keep imports consistent across the file.

app/Models/Snapshot.php (1)

202-210: ⚡ Quick win

Same missing isResolved() guard as BackupJob::scopeForCurrentOrg.

id() is called directly without checking isResolved() first. OrganizationScope::apply() always guards id() — calling it unguarded may produce silent zero-row results (if id() returns null) or throw in non-HTTP contexts.

🛡️ Proposed fix

 public function scopeForCurrentOrg(Builder $query): Builder
 {
-    $orgId = app(CurrentOrganization::class)->id();
+    $currentOrg = app(CurrentOrganization::class);
+
+    if (! $currentOrg->isResolved()) {
+        return $query->whereRaw('0 = 1'); // No org context → no results
+    }
+
+    $orgId = $currentOrg->id();

     return $query->whereHas('databaseServer', function (Builder $sq) use ($orgId) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/Snapshot.php` around lines 202 - 210, scopeForCurrentOrg calls
app(CurrentOrganization::class)->id() without first checking isResolved(), which
can return null in non-HTTP contexts; mirror the fix used in
BackupJob::scopeForCurrentOrg: call
app(CurrentOrganization::class)->isResolved() and if it is not resolved return a
query that yields no results (e.g., $query->whereRaw('0 = 1')), otherwise
retrieve the org id and run the existing whereHas on the databaseServer
relationship (preserving the withoutGlobalScope(OrganizationScope::class) and
whereRaw('organization_id = ?', [$orgId])).

tests/Feature/Services/Backup/LocalVolumeStorageTest.php (1)

38-56: ⚡ Quick win

Prefer Volume::factory()->create([...]) over raw Volume::create() with Organization::first().

Same guideline violation as in CreateTest.php. Even when overriding config, the factory pattern is preferred and avoids the fragile Organization::first() call.

♻️ Proposed refactor

-    $volumeWithRoot = Volume::create([
-        'name' => 'Volume with root key',
-        'type' => 'local',
-        'config' => ['root' => $tempDir],
-        'organization_id' => \App\Models\Organization::first()->id,
-    ]);
+    $volumeWithRoot = Volume::factory()->local()->create([
+        'name' => 'Volume with root key',
+        'config' => ['root' => $tempDir],
+    ]);
 
 ...
 
-    $volumeWithPath = Volume::create([
-        'name' => 'Volume with path key',
-        'type' => 'local',
-        'config' => ['path' => $tempDir],
-        'organization_id' => \App\Models\Organization::first()->id,
-    ]);
+    $volumeWithPath = Volume::factory()->local()->create([
+        'name' => 'Volume with path key',
+        'config' => ['path' => $tempDir],
+    ]);

As per coding guidelines: "When creating models for tests, use factories. Check if the factory has custom states before manually setting up the model."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Services/Backup/LocalVolumeStorageTest.php` around lines 38 -
56, Tests are creating Volume models with Volume::create([...]) and calling
Organization::first(), which violates the factory-first guideline; replace these
Volume::create(...) usages with Volume::factory()->create(...) and pass the
overridden attributes (name, type, config, organization_id) to the factory call
(use Organization factory to create/get an organization via
Organization::factory()->create() or reuse a created org) so the test uses model
factories instead of direct creates; update the instances around Volume::create
for $volumeWithRoot and $volumeWithPath and any related assertions that rely on
those variables.

tests/Feature/DatabaseServer/CreateTest.php (1)

13-18: ⚡ Quick win

Use Volume::factory() instead of raw Volume::create() with Organization::first().

This pattern repeats across all Volume setups in this file (Lines 13, 106, 145, 264, 296, 313, 330, 352, 429, 470, 476). Two issues:

1. Guideline violation – tests should create models via factories, not raw create().
2. Fragility – Organization::first() returns ?Organization; if the Pest bootstrap ever stops seeding an org, every ->id call throws a PHP fatal error with no descriptive failure.

The Volume factory already has a local() state; use it with an org context:

♻️ Proposed refactor

-    $volume = Volume::create([
-        'name' => 'Test Volume',
-        'type' => 'local',
-        'config' => ['path' => '/var/backups'],
-        'organization_id' => \App\Models\Organization::first()->id,
-    ]);
+    $volume = Volume::factory()->local()->create();

If the factory doesn't yet carry an organization_id from the global test context, a small helper in tests/Pest.php (e.g. currentOrganization()) or an ->withOrganization() factory state removes the repeated Organization::first() call entirely.

As per coding guidelines: "When creating models for tests, use factories. Check if the factory has custom states before manually setting up the model."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/DatabaseServer/CreateTest.php` around lines 13 - 18, Replace
direct Volume::create([...]) + Organization::first()->id with the Volume
factory: use Volume::factory()->local()->for($org, 'organization')->create()
where $org is provided by a test helper (e.g. currentOrganization()) or an
Organization factory; alternatively add/use a factory state like
->withOrganization() to attach the organization. Update each occurrence (the
Volume::create calls) to use Volume::factory(), the local() state, and .for(...)
or the new state to eliminate Organization::first() and avoid null fatal errors.

app/Models/DatabaseServerSshConfig.php (1)

15-29: 💤 Low value

PHPDoc block missing organization_id and organization entries.

Same gap as Agent.php — the existing PHPDoc documents all fields and relations, so the new ones should be added for consistency and IDE support.

📝 Proposed additions

  * `@property` string|null $key_passphrase
  * `@property` Carbon|null $created_at
  * `@property` Carbon|null $updated_at
+ * `@property` string $organization_id
  * `@property-read` Collection<int, DatabaseServer> $databaseServers
+ * `@property-read` Organization $organization

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/DatabaseServerSshConfig.php` around lines 15 - 29, The PHPDoc for
the DatabaseServerSshConfig model is missing the organization relation and
foreign key—update the docblock in the DatabaseServerSshConfig class to add the
organization_id property and the organization relation (e.g., add a `@property`
string $organization_id and a `@property-read` Organization $organization) so IDEs
and static analyzers can see the relation; ensure the class name
DatabaseServerSshConfig and the existing `@property-read` Collection<int,
DatabaseServer> $databaseServers stay intact.

app/Models/Agent.php (1)

17-38: 💤 Low value

PHPDoc block is missing entries for the new organization_id field and organization relation.

The existing class-level PHPDoc documents every property and relation. The new additions lack corresponding entries.

📝 Proposed additions

  * `@property` Carbon|null $updated_at
+ * `@property` string $organization_id
  * `@property-read` Collection<int, DatabaseServer> $databaseServers
  * `@property-read` int|null $database_servers_count
  * `@property-read` Collection<int, AgentJob> $agentJobs
  * `@property-read` int|null $agent_jobs_count
+ * `@property-read` Organization $organization

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/Agent.php` around lines 17 - 38, Update the class-level PHPDoc in
Agent.php to document the new organization fields and relation: add a `@property`
(string|null) $organization_id entry and a `@property-read` Organization
$organization (and optionally `@property-read` int|null $organization_count if you
expose a count) so the new organization_id attribute and organization() relation
are reflected alongside the existing properties and relations.

tests/Feature/Auth/OAuthTest.php (1)

96-99: ⚡ Quick win

Stop seeding raw role attributes in these fixtures.

This PR moves role state to the organization_user pivot, but these tests still pass role into User::factory()->create(). Please seed the org membership/role through the factory helper or by attaching the target organization explicitly, so the setup matches what roleIn(...) actually reads.

As per coding guidelines, "When creating models for tests, use factories. Check if the factory has custom states before manually setting up the model."

Also applies to: 343-343, 364-364, 520-520, 542-542

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/Feature/Auth/OAuthTest.php` around lines 96 - 99, The test is
incorrectly seeding the user's role via User::factory()->create(['role' => ...])
even though role is stored on the organization_user pivot and read via
roleIn(...); update the setup for $existingUser (and the other occurrences) to
remove the raw 'role' attribute from User::factory()->create() and instead
assign the role through the org membership: either use an available factory
helper/state that creates the organization membership with the desired role
(e.g. a custom User factory state like withOrganizationRole or the project’s
helper used elsewhere), or create the Organization and attach the user to it by
creating an organization_user pivot record with the appropriate role so
roleIn($org) will reflect the correct role for $existingUser.

app/Livewire/Settings/DeleteUserForm.php (1)

28-28: ⚡ Quick win

Use Livewire SPA redirect convention here.

Line 28 uses navigate: false; project convention requires returning $this->redirect(..., navigate: true) for in-app navigation consistency.

Proposed change

-        $this->redirect(route('login'), navigate: false);
+        return $this->redirect(route('login'), navigate: true);

As per coding guidelines, in Livewire components you should return $this->redirect() with navigate: true for SPA-like navigation.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/Settings/DeleteUserForm.php` at line 28, In the DeleteUserForm
Livewire component replace the current SPA redirect call that uses navigate:
false with the Livewire SPA convention: return the redirect and set navigate:
true; specifically change the $this->redirect(route('login'), navigate: false)
invocation in class DeleteUserForm (method performing the post-delete redirect)
to return $this->redirect(route('login'), navigate: true) so the component
performs in-app navigation correctly.

app/Livewire/OrganizationSwitcher.php (1)

19-31: ⚡ Quick win

Return the Livewire redirect instead of discarding it.

This action currently calls $this->redirect(...) but keeps a void signature and drops the return value. The repo convention for Livewire components is to return the redirect response when using navigate: true. As per coding guidelines: "In Livewire components, return $this->redirect() with navigate: true for SPA-like navigation."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Livewire/OrganizationSwitcher.php` around lines 19 - 31, The switchOrg
method currently has a void signature and discards the Livewire redirect; change
its signature to return the redirect response and return the
$this->redirect(...) call (with navigate: true) instead of dropping it. Locate
switchOrg (uses Organization::findOrFail, auth()->user(), and
app(CurrentOrganization::class)->switchTo) and update the method return type and
final statement to return the redirect so the Livewire SPA navigation behavior
is preserved.

app/Models/User.php (1)

118-119: 💤 Low value

pendingPivotRole is exposed as public — consider tightening visibility.

This is a transient hand-off slot from UserFactory to a creation hook, but as a public property it can also be read/written by any caller (controllers, Livewire, blade) and is not guarded against accidental mutation. If the contract really is "factory-only," protected (with a setter) or even moving the role hand-off to factory state metadata would communicate intent better and keep the model surface area lean.

Not blocking — just a nudge for the data-flow shape.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/Models/User.php` around lines 118 - 119, The public transient property
User::$pendingPivotRole should be tightened: change its visibility to protected
and add a minimal factory-only setter method (e.g.,
User::setPendingPivotRole(UserRole $role): void) that UserFactory calls to pass
the pivot role, or alternatively move the hand-off into the factory's state
metadata instead of storing it on the model; update references in UserFactory to
use the new setter (or factory metadata) and keep the property non-public to
prevent accidental external reads/writes.